I have verified the changes with a local build:

• the gRPC API works fine, and
• I see the desired output from the terminal too. For example: ./arduino-cli lib list --all --fqbn arduino:megaavr:nona4809 --format json provides the expected output with the additional provides_includes info.

Thank you, @cmaglie!

Please tag the code once this is merged. Thanks!

I think this was a breaking change, as now headers which are not part of the includes of the library.properties can't be resolved anymore when compiling a sketch that includes them. For example the library "Corsair Lighting Protocol" only declares a single header file which is fine for normal users (https://github.com/Legion2/CorsairLightingProtocol/blob/82c434f6fb2177faccde82b2e41e5210b009382a/library.properties#L10). But for other uses cases other headers must be used, which are not declared by the library because they should not be used when a user adds the library in the Arduino IDE to the sketch. With arduino cli 0.13.0 the sketches which include the headers that are not declared by the library can't be compiled because the includes can't be resolved. I think this is because of the changes in this PR. With arduino cli 0.12.1 the sketches compiled without a problem.

Alternatives for CLPUtils.h: []
ResolveLibrary(CLPUtils.h)
  -> candidates: []
D:\Dokumente\Informatik\Arduino\libraries\CorsairLightingProtocol\examples\DeviceIDTool\DeviceIDTool.ino:19:10: fatal error: CLPUtils.h: No such file or directory
 #include <CLPUtils.h>
          ^~~~~~~~~~~~
compilation terminated.
Error during build: exit status 1

In https://arduino.github.io/arduino-cli/latest/library-specification/ the current behavior is not described, so I think is a bug.

Hi @Legion2. I also came to the same conclusion. We are using this bug report: #960 to track the issue.